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Abstract: Agent technology becomes more and more importance in the e-business domain. The corKepts 
and technology have been brought to a stage where they are useable in real applications, anfit^fe is a 
growing understanding of how to apply them to practical problems. Component meth^doragies have 
proved to be successful in increasing speed to market of software development prd^ct^^owering the 
development cost and providing better quality. 

In this paper, we propose systemical development process using component an^VML(Unified Modeling 
Language) technology to analysis, design and develop e-business agent. The mbS^^PD( m -business Agent- 
Component Based Development) process is an attempt to consider all uOI|^best features of existing 
AOSE (Agent Oriented Software Engineering) methodologies while gij^tmmnj agent-oriented concepts in 
the same underlying semantic framework used by UML, the staraK^Modeling language for Object 
Oriented Software Engineering. Finally we describe how these cCn»pts may assist in increasing the 
efficiency and reusability in business application and e-business a|p^cTevelopment. 

Keywords : M-Business Agent (mbA), mbA-CBD Reference Ard2^cture, mbA-Spec, CBD 

1. Introdift&on 

Recently the software lifecycle is getting shoi*e\ arid web service for paradigm of next generation 
information technology is more focused on wbife^^usiness model has developed very rapidly. Therefore, 
the development of software which is mjjtfeWunctionable, various, stable software, the key of business 
domain. According to these requiremeflEViot only the component having exchangeable module that 
performs independent business ancL^jpbn in software system but also the utilization of agent in e- 
business domain become more ncfeJWufnt is important to produce the agent service based on component 
technology that is change to\eplaNement and portability toward developing the software having high 
productability [1] [2] . 




In this paper, we propcw*l^!ibft.-CBD process. This proposed posses applies mbA model notation and role 
model, goal model, a^&pt^rture model and interaction model in the view of agent. Simultaneously, these 4 
models considerec^/lhbA model. The mbA Model can define agent characteristics and the relations 
among agents^ltfy same time, component is possibly constructed on mbA specification. In addition the 
process are r//G^$ted though of e business agent models the case study of component information search 



2. Related Works 
2.1 Agent Concept Model 



An agent is an atomic autonomous entity that is capable of performing some useful function. The 
functional capability is captured as the agent's services. A service is the knowledge level analogue of an 
object's operation. The quality of autonomy means that an agent's actions are not solely dictated by 
external events or interactions, but also by its own motivation. We capture this motivation in an attribute 
named purpose. The purpose will, for example, influence whether an agent agrees to a request to perform a 
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service and also the way it provides the service. Software Agent and Human Agent are specialization of 
agent [3]. 

Figure 1 gives an informal agent-centric overview of how these concepts are inter-related. The role concept 
allows the part played by an agent to be separated logically from the identity of the agent itself. The 
distinction between role and agent is analogous to that between interface and class: a role describes the 
external characteristics of an agent in a particular context. An agent may be capable of playing several roles, 
and multiple agents may be able to play the same role. Roles can also be used as indirect referencesto 
agents. This is useful in defining re-usable patterns. Resource is used to represent non-autonomous errfsy^l 
such as databases or external programs used by agents. Standard object-oriented concepts are ade^ 
modeling resources^]. 
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Figure 1. Agent Concept Model 
2.2 Reference Architecture of mbA-CBD 



ss fumol 




uct component reference architecture, agent is classified in general agent type and e- 
jpn attribute. Figure 2 is a component and meta architecture of based on all above described 
agent [5] [6]. 

ie architecture is consisted of dimension, which has 14 general types and 11 concrete business agent 
Fwith domain oriented component architecture. These two classification areas tend to be independent 
for^each cross-referenced. Each area has its own horizontal and vertical characteristics. General agent types 
are corresponding to agent platform and application. It is possible to develop agent system or application 
by the referencing architecture. The technology of agent can be applied to business domain. 

Developed component is classified by the reference architecture and is placed according to general agent 
type and business attribute. In case agent is applied to the agent system or business domain, system is 
possibly to build up by identifying component related to business domain and combining it. 
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Figure 2. mbA-CBD Reference Archite 




3. mbA-CBD Process* V 

As we suggested mbA-CBD reference architecture in previous rqMarch[5], component development process 
based architecture is a set of activities and associated resui|\ vtrfiich lead to the production of a component 
as shown in figure 3. These may involve the developm^h^^ component from mbA specification by using 
UML model. Here, our main concern is the specificatifti^orkflow. 
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Figure 3. mbA-CBD process 



In addition, we consider systemical development process using AUML and mbA model technology to 
analyze, design, and develop e-business agent. The domain analysis specification, design model, 
implemented component, which are produced though the process, are stored in the repository [6]. 
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3.1 mbA Requirements Identification Phase 



The requirement of agent should be first identified in desired business system. The primary property of 
agent is able to analyze after that the description for specific agent platform and the sorts of essential 
properties should be understood. At the same time, it is very important to consider weather the 
requirement, which is already defined, is corresponding to agent type in reference architecture and what 
business concept is focused on.. 

For the e-business domain analysis, UML approach is used. Diagrams used in problem domain analy^we* 
use case diagram. Use case diagram is a diagram that shows a set of use cases and actors arfflOkeir 
relationships. It supports the behavior of a system by modeling static aspects of a system. 

Also, domain analysis is presented on entire domain concept and scenario using^a^wt^ diagram. 
Requirement analysis is defined through use case diagram, and use case description. X^^V 



3.2 mbA Specification Development 

icatioi 



Agent specification based on user s requirement creates mbA Specificat 
that are acquired though the specification phase, becomes the main 
new components. 




* models. These products 
to identify and development 



As mentioned, in order to provide a further degree of expressiveC^T^ibA Model extends the UML meta- 
model by adding a number of elements to it. This section desa^HaJPne notation that mbA Model represents 
graphically the instances of these new meta-elements in the^iajWms. 



Figures 4 provide a summary of the symbols rep 
respectively. It is notice that symbols are associated 
which doesn't mention here. 



|eming the mbA Model concepts and relations 
Iments natively included in the UML meta-model, 



The usages of relationships are as follows^^% 

• Implication: This relation links^orjfeVjrjmore elements that have an attribute of type state to a single 

:e of t^^^ite. 
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Figure 4. mbA Model Notation 



• Assignment: This relation links an element of type Autonomous Entity to an element that has an attribute 
of type Autonomous Entity. The semantics are such that the assignment from one Autonomous Entity to 
another following the direction of the arrow. 
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• Data flow: This relation links a Data Prosumer to an Information Entity that is produced or consumed. 
This is the same relation as the Object Flow relation defined in UML and therefore the same symbol is used 
here. 



3.2.1 mbA Identification and Role Model Creation 



This focuses on the individual Agents and Roles. For each agent /role it uses scheme supported by diagrams 
to its characteristics such as what goals it is responsible for, what events it needs to sense, what resourcegjt 
controls, what tasks it informs how to perform, 'behavior rules', etc. 

Agent identification uses mbA-CBD reference metrics as figure 5. Agent naming is referenced fro 
description and role model is created using mbA model notation. Also, mbA-CBD reference mei 
give a classification code. 
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Figure 5. mt 



.2.2 



reference metrics 



oal Model Creation 



This shows Goals, Tasks, States ^fjdftfWflependencies among them. Goals and Tasks are both associated 
with States, so that they can belinla|^by logical dependencies to form graphs that show e.g. that achieving 
a set of sub-goals implies tharcNjigher level Goal is achieved, and how Tasks can be performed to achieve 
Goals. Graphs showing tepmfam dependencies can also be drawn, and we have found UML Activity 
Diagram notation useful 



f/V 3.2.3 mbA Interaction Model Creation 



This model hkffl^frfs which, why and when agents/roles need to communicate leaving all the details about 
how the cfljmrrmnication takes place to the design process. The interaction model is typically refined 
through ^^ral iterations as long as new interactions are discovered. It can be conveniently expressed by 
mean^^S^ number of interaction diagrams. This model is interaction centric and shows the initiator, the 
jf^A^Jtrs, the motivator of an interaction plus other optional information such as the trigger condition 
and lie information achieved and supplied by each participant. 

3.2.4 mbA Architecture Model Creation 

This model shows agents relationship to negotiate and coordinate in agent area. It considers the business 
actor and domain concept. An agent area is where software agents meet and interact in the target 
architecture. The agent areas can be distributed on different hosts, and facilitate means for efficient inter- 
agent communication. 
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There are two main types of agent area. One is the area where the agents advertise their capabilities, 
communicate with other agents. The other is the user-client where the user interacts with agents. 



3.2.5 mbA Specification Description 

The mbA specification description is based previous models as role model, goal model, interaction model 
and architecture model. mbA specification is shown functional and non-functional elements in figure 6. 
The functional elements are described to use class diagram and sequence diagram. 



3.3 mbA-CBD Specification Development 



We have attempted summarize the process tasks into the four stages: e-business concept model^^> 
static model, e-business interface identification and component spec description. * 
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Figure 6. mbA Specific 
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The specification development takes as its input from ^effi^ements a use case model, mbA models and a 
mbA-spec. It also uses information about existing SAra^fre assets, such as legacy systems, packages, and 
databases, and technical constrains, such as use o^^Rcular architectures or tools. It generates a set of 
component specifications and a component ^jtei^tecture. The component specifications include the 
interface specifications they support or deDena*bn, and the component architecture shows how the 
components interact with each other. 



3 s 



The identified information based x>n#c\m^onent users and performance must be provided in specification 
form for integration. Also, this infl^^^tion can be provided and acquired by producer, consumer and agent 
in interoperating system. The i^prmation of component design and development, and also functional and 
non-functional informatiorLj^u^ be provided by producer, and agent must provide the commercial 
information with this. T^i^rjbrmation is the important standard for choice and the ground for reuse to 
acquire the component^Fi^re 7 shows this information. 
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Figure 7. Component specification 
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3.4 Component Adaptation 



These output are used in the provisioning phase to determine what components to build or buy, in the 
assembly phase as an input to test scripts. 

The provisioning phase ensures that the necessary components are made available, either by building them 
form scratch, buying them from a third party, or reusing, integrating, mining, or otherwise modifying an 
existing component or other software. The provisioning phase also includes unit testing the compor 
prior to assembly. 

The assembly phase takes all the components and puts them together with existing software nda 
suitable user interface to form an application that meets the business need. The application is pStord to the 
test phase for system and user acceptance testing. ^^Jj * 

4. Example of mbA- Specification 



In this thesis, we focused on mbA specification so, case study only mei 
identification and specification development. The example is componenyii^l^i, 
agent finds the information of the component to be registered newly. 



*ed n 

ation search agent. The 



ed mbA requirements 



4.1 mbA Requirements Identification for Compong^^lftformation Search Agent 

The requirement identification simply presented by use case ^y^3m as figure 8. The actors are user and 
agent that is agent family. 
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Figu^e^^^e Case Diagram of Component Information Search Agent 
4.2 mbA-$^prDevelopment of Component Information Search Agent 

The mbA canolAtfi/identify based on use case diagram and using mbA-CBD reference metrics. Figure 9 
presented id^Hp^d mbA as user, search and collection agent. 
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Figure 9. mbA-CBD Metrics of Component Information Search Agent 
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Figure 10 represents overall role of component information search agent. The roles describe the external 
characteristics of identified agent. Also, The goal model in Figure 11 shows the main goal of the component 
information search agent. The CteateNewList goal is achieved when lower goal successfully completed. 
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Figure 10. Role Model of Component Information Seana^^^ 
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The following picture ^ic^i^s^an example the interaction model describing the Information Request 
interaction between tW^GWnponent Information Gather and Component Information Assistant roles. 
Figure 13 shows an jTfJmAture model. It represents overall system structure of Component Information 
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Figure 12. Interaction Model of Component Information Search Agent 
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Figure 13. Architecture Model of Component Information Search Agent 

Figure 14 present User Agent specifications consists of mbA resource information and two mod^^WLfle 
resource information is basic elements such as name, e-business type and general agent type ac^lfdjig to 
mbA-CBD reference architecture and classification code. Information and operation moflelfprovide 
inter/external structure and interoperation of agents. These referred mbA-CBD specificatijJrt^velopment 
phase. 

Following are results of a study on the "Leades INdustry-university Cooperati^nVroject, supported by the 
Ministry of Education, Science & Technology (MEST) 2013 

5. Conclusion ^^^S 

In this paper, each characteristic in the view of agent and comnn^ are defined and mbA-CBD process is 
proposed to develop e-business agent. Defining mbA specififa^Wt of whole entire agent has e-business 
agent information more systemical and intuitional then afcp jpcludes more information. Introducing the 
systemical process and mbA-CBD reference model of j^fesfcness agent can provide the efficiency by the 
component easily. Also, the specification can be the gfcOTenne to choose desired component and be reused 
as based more for component creation. ^ 



For the further works, the definition and detail methods should be required based on mbA specification for 
component development and assemble. I«£j\rmore, the comparison and verification are needed though 
the cases study of implementation. 
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Figure 14. mbA-Spec. of User Agent 
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